Monetary transaction system

ABSTRACT

Embodiments are directed to monetary transaction system for conducting monetary transactions between transaction system subscribers and other entities. In one scenario, the monetary transaction system includes a mobile device that runs a monetary transaction system application. The monetary transaction system also includes a subscriber that has a profile with the system. The subscriber indicates a transaction that is to be performed with the monetary transaction system. The system further includes a monetary transaction system processor that performs the transactions specified by the subscriber including communicating with a monetary transaction database to determine whether the transaction is permissible based on data indicated in the subscriber&#39;s profile. The monetary transaction system also includes at least one entity that is to be involved in the specified transaction, where the entity has a profile with the monetary transaction system. This entity may be a person, a retail store, an agent or other entity.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/569,348, filed Sep. 12, 2019, entitled “MONETARY TRANSACTION SYSTEM,”which is a continuation of U.S. patent application Ser. No. 15/809,872,filed Nov. 10, 2017, entitled “Monetary Transaction System”, which is acontinuation of U.S. patent application Ser. No. 15/201,152, now issuedas U.S. Pat. No. 9,892,386, filed Jul. 1, 2016, entitled “MonetaryTransaction System”, which is a continuation of U.S. patent applicationSer. No. 14/213,543, filed Mar. 14, 2014, entitled “Monetary TransactionSystem”, which is a continuation of U.S. patent application Ser. No.13/964,707, filed Aug. 12, 2013, entitled “Monetary Transaction system”,which application is a continuation of U.S. patent application Ser. No.13/484,199 now issued as U.S. Pat. No. 8,538,845, filed May 30, 2012,entitled “Monetary Transaction System”, which application claimspriority to and the benefit of U.S. Provisional Application Ser. No.61/522,099, filed on Aug. 10, 2011, entitled “Mobile Wallet Platform”,and U.S. Provisional Application Ser. No. 61/493,064, filed on Jun. 3,2011, entitled “Mobile Wallet Platform”. All of the aforementionedapplications are incorporated by reference herein in their entirety.

BACKGROUND

Mobile phones and other digital devices have become increasingly popularin recent years. Many mobile device users use their devices to performcountless different daily tasks. For instance, mobile devices allowusers to check email, send and receive instant messages, check calendaritems, take notes, set up reminders, browse the internet, play games orperform any number of different things using specialized applications or“apps”. These applications allow mobile devices to communicate withother computer systems and perform a wide variety of network-connectedtasks previously not possible with a mobile device.

BRIEF SUMMARY

Embodiments described herein are directed to monetary transaction systemfor conducting monetary transactions between transaction systemsubscribers and other entities. In one embodiment, the monetarytransaction system includes a mobile device configured to run a monetarytransaction system application. The monetary transaction system alsoincludes a monetary transaction system subscriber that has a profilewith the system. The subscriber indicates, via the monetary transactionsystem application, one or more specified transactions that are to beperformed using the monetary transaction system. The system furtherincludes a monetary transaction system processor that performs thetransactions specified by the subscriber. Performing these transactionsincludes communicating with a monetary transaction database to determinewhether the transaction is permissible based on data indicated in thesubscriber's profile.

The monetary transaction system also includes at least one entity thatis to be involved in the specified transaction, where the entity has aprofile with the monetary transaction system. This entity may be aperson, a retail store, an agent or other entity. The subscriber mayhave access to a bank account, or may be an “unbanked user” that doesnot have access to a bank account. Each of the terms included above willbe described in greater detail below in conjunction with the drawings.

The monetary transaction system may be used for many different tasksincluding enrolling a customer for a mobile wallet, adding a storedvalue account (either hosted by a mobile wallet platform or a thirdparty), adding a bank or credit union account to a mobile wallet, addinga debit or credit card account to a mobile wallet, depositing funds in amobile wallet, withdrawing funds from a mobile wallet, paying bills froma mobile wallet, topping up a prepaid mobile account through a mobilewallet, transferring funds through a mobile wallet (nationally orinternationally), making in-store purchases using a mobile wallet, andvarious other tasks as described herein below.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Additional features and advantages will be set forth in the descriptionwhich follows, and in part will be apparent to one of ordinary skill inthe art from the description, or may be learned by the practice of theteachings herein. Features and advantages of embodiments describedherein may be realized and obtained by means of the instruments andcombinations particularly pointed out in the appended claims. Featuresof the embodiments described herein will become more fully apparent fromthe following description and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

To further clarify the above and other features of the embodimentsdescribed herein, a more particular description will be rendered byreference to the appended drawings. It is appreciated that thesedrawings depict only examples of the embodiments described herein andare therefore not to be considered limiting of its scope. Theembodiments will be described and explained with additional specificityand detail through the use of the accompanying drawings in which:

FIG. 1 illustrates a monetary transaction system architecture in whichembodiments described herein may operate.

FIG. 2 illustrates an alternate example embodiment of a monetarytransaction system.

FIG. 3 illustrates an example data flow for performing a subscriberdeposit via a mobile wallet.

FIG. 4 illustrates an example data flow for performing a subscriberwithdrawal via a mobile wallet.

FIGS. 5A and 5B illustrate example data flows for performingsubscriber-to-subscriber and subscriber-to-non-subscriber eMoneytransfers via a mobile wallet, respectively.

FIGS. 6A and 6B illustrate example data flows for performingsubscriber-to-subscriber and subscriber-to-non-subscriber internationaleMoney transfers via a mobile wallet, respectively.

FIG. 7 illustrates an example data flow for performing a subscriberairtime purchase via a mobile wallet.

FIG. 8 illustrates an example data flow for performing asubscriber-initiated bill pay via a mobile wallet.

FIG. 9 illustrates an example data flow for performing asubscriber-initiated retail purchase via a mobile wallet.

FIGS. 10A and 10B illustrate example data flows for requesting andrepaying micro-loans via a mobile wallet, respectively.

FIG. 11A illustrates an example data flow of a subscriber receiving adirect deposit via a mobile wallet.

FIG. 11B illustrates an example data flow of a subscriber receiving agovernmental welfare payment via a mobile wallet.

FIG. 12A illustrates an example data flow of an agent administratordistributing eMoney via a mobile wallet.

FIG. 12B illustrates an example data flow of an agent company making adeposit using a mobile wallet.

FIG. 13 illustrates an example data flow of an agent company making awithdrawal using a mobile wallet.

FIG. 14 illustrates an example data flow of a subscriber making adeposit at an agent branch using a mobile wallet.

FIG. 15 illustrates an example data flow of a subscriber making adeposit with a non-agent using a mobile wallet.

FIG. 16 illustrates an example data flow of a subscriber making awithdrawal with an agent using a mobile wallet.

FIG. 17A illustrates an example data flow of a subscriber making awithdrawal from an ATM using a mobile wallet.

FIG. 17B illustrates an example data flow of a subscriber-to-subscribermoney transfer using a mobile wallet.

FIG. 17C illustrates an example data flow of asubscriber-to-non-subscriber money transfer using a mobile wallet.

FIG. 18A illustrates an example data flow of a subscriber-to-subscriberinternational money transfer using a mobile wallet.

FIG. 18B illustrates an example data flow of asubscriber-to-non-subscriber international money transfer using a mobilewallet.

FIG. 19A illustrates an example data flow of a subscriber-to-subscriberinternational money transfer using a mobile wallet.

FIG. 19B illustrates an example data flow of anon-subscriber-to-subscriber international money transfer using a mobilewallet.

FIG. 20A illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 20B illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 20C illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 20D illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 20E illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 20F illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21A illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21B illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21C illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21D illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21E illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21F illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21G illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21H illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 21I illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22A illustrates a flow chart of actions in accordance withdisclosed embodiments. FIG. 22B illustrates a flow chart of actions inaccordance with disclosed embodiments.

FIG. 22C illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22D illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22E illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22F illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22G illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22H illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22I illustrates a flow chart of actions in accordance withdisclosed embodiments.

FIG. 22J illustrates a flow chart of actions in accordance withdisclosed embodiments.

DETAILED DESCRIPTION

Embodiments described herein are directed to monetary transaction systemfor conducting monetary transactions between transaction systemsubscribers and other entities. In one embodiment, the monetarytransaction system includes a mobile device configured to run a monetarytransaction system application. The monetary transaction system alsoincludes a monetary transaction system subscriber that has a profilewith the system. The subscriber indicates, via the monetary transactionsystem application, one or more specified transactions that are to beperformed using the monetary transaction system. The system furtherincludes a monetary transaction system processor that performs thetransactions specified by the subscriber. Performing these transactionsincludes communicating with a monetary transaction database to determinewhether the transaction is permissible based on data indicated in thesubscriber's profile.

The monetary transaction system also includes at least one entity thatis to be involved in the specified transaction, where the entity has aprofile with the monetary transaction system. This entity may be aperson, a retail store, an agent or other entity. The subscriber mayhave access to a bank account, or may be an “unbanked user” that doesnot have access to a bank account. Each of the terms included above willbe described in greater detail below in conjunction with the drawings.

The monetary transaction system may be used for many different tasksincluding enrolling a customer for a mobile wallet, adding a storedvalue account (either hosted by a mobile wallet platform or a thirdparty), adding a bank or credit union account to a mobile wallet, addinga debit or credit card account to a mobile wallet, depositing funds in amobile wallet, withdrawing funds from a mobile wallet, paying bills froma mobile wallet, topping up a prepaid mobile account through a mobilewallet, transferring funds through a mobile wallet (nationally orinternationally), making in-store purchases using a mobile wallet, andvarious other tasks as described herein below.

The following discussion now refers to a number of methods and methodsteps or acts that may be performed. It should be noted, that althoughthe method steps may be discussed in a certain order or illustrated in aflow chart as occurring in a particular order, no particular ordering isnecessarily required unless specifically stated, or required because astep is dependent on another step being completed prior to the stepbeing performed.

Embodiments of the mobile transaction system or “mobile wallet platform”described herein may comprise or utilize a special purpose orgeneral-purpose computer including computer hardware, such as, forexample, one or more processors and system memory, as discussed ingreater detail below. Embodiments described herein also include physicaland other computer-readable media for carrying or storingcomputer-executable instructions and/or data structures. Suchcomputer-readable media can be any available media that can be accessedby a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions inthe form of data are computer storage media. Computer-readable mediathat carry computer-executable instructions are transmission media.Thus, by way of example, and not limitation, embodiments describedherein can comprise at least two distinctly different kinds ofcomputer-readable media: computer storage media and transmission media.

Computer storage media includes RAM, ROM, EEPROM, CD-ROM, solid statedrives (SSDs) that are based on RAM, Flash memory, phase-change memory(PCM), or other types of memory, or other optical disk storage, magneticdisk storage or other magnetic storage devices, or any other mediumwhich can be used to store desired program code means in the form ofcomputer-executable instructions, data or data structures and which canbe accessed by a general purpose or special purpose computer.

A “network” is defined as one or more data links and/or data switchesthat enable the transport of electronic data between computer systemsand/or modules and/or other electronic devices. When information istransferred or provided over a network (either hardwired, wireless, or acombination of hardwired or wireless) to a computer, the computerproperly views the connection as a transmission medium. Transmissionmedia can include a network which can be used to carry data or desiredprogram code means in the form of computer-executable instructions or inthe form of data structures and which can be accessed by a generalpurpose or special purpose computer. Combinations of the above shouldalso be included within the scope of computer-readable media.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media to computerstorage media (or vice versa). For example, computer-executableinstructions or data structures received over a network or data link canbe buffered in RAM within a network interface module (e.g., a networkinterface card or “NIC”), and then eventually transferred to computersystem RAM and/or to less volatile computer storage media at a computersystem. Thus, it should be understood that computer storage media can beincluded in computer system components that also (or even primarily)utilize transmission media.

Computer-executable (or computer-interpretable) instructions comprise,for example, instructions which cause a general purpose computer,special purpose computer, or special purpose processing device toperform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediateformat instructions such as assembly language, or even source code.Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that various embodiments may bepracticed in network computing environments with many types of computersystem configurations, including personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, tablets, pagers, routers, switches, and the like. Embodimentsdescribed herein may also be practiced in distributed systemenvironments where local and remote computer systems that are linked(either by hardwired data links, wireless data links, or by acombination of hardwired and wireless data links) through a network,each perform tasks (e.g. cloud computing, cloud services and the like).In a distributed system environment, program modules may be located inboth local and remote memory storage devices.

In this description and the following claims, “cloud computing” isdefined as a model for enabling on-demand network access to a sharedpool of configurable computing resources (e.g., networks, servers,storage, applications, and services). The definition of “cloudcomputing” is not limited to any of the other numerous advantages thatcan be obtained from such a model when properly deployed.

For instance, cloud computing is currently employed in the marketplaceso as to offer ubiquitous and convenient on-demand access to the sharedpool of configurable computing resources. Furthermore, the shared poolof configurable computing resources can be rapidly provisioned viavirtualization and released with low management effort or serviceprovider interaction, and then scaled accordingly.

A cloud computing model can be composed of various characteristics suchas on-demand self-service, broad network access, resource pooling, rapidelasticity, measured service, and so forth. A cloud computing model mayalso come in the form of various service models such as, for example,Software as a Service (“SaaS”), Platform as a Service (“PaaS”), andInfrastructure as a Service (“IaaS”). The cloud computing model may alsobe deployed using different deployment models such as private cloud,community cloud, public cloud, hybrid cloud, and so forth. In thisdescription and in the claims, a “cloud computing environment” is anenvironment in which cloud computing is employed.

Additionally or alternatively, the functionally described herein can beperformed, at least in part, by one or more hardware logic components.For example, and without limitation, illustrative types of hardwarelogic components that can be used include Field-programmable Gate Arrays(FPGAs), Program-specific Integrated Circuits (ASICs), Program-specificStandard Products (ASSPs), System-on-a-chip systems (SOCs), ComplexProgrammable Logic Devices (CPLDs), and other types of programmablehardware.

Still further, system architectures described herein can include aplurality of independent components that each contribute to thefunctionality of the system as a whole. This modularity allows forincreased flexibility when approaching issues of platform scalabilityand, to this end, provides a variety of advantages. System complexityand growth can be managed more easily through the use of smaller-scaleparts with limited functional scope. Platform fault tolerance isenhanced through the use of these loosely coupled modules. Individualcomponents can be grown incrementally as business needs dictate. Modulardevelopment also translates to decreased time to market for newfunctionality. New functionality can be added or subtracted withoutimpacting the core system.

Various terminology will be used herein to describe the monetarytransaction system (also referred to as a “mobile wallet platform”,“mobile wallet program” or “mobile wallet transaction system”). The term“agent” is used to refer to an individual with mobile financial services(mFS) transaction system tools and training to support specific mFSfunctions. These mFS functions include subscriber registration andactivation, and the deposit and withdrawal of funds from the mFStransaction system. Agents are representatives of the mFS transactionsystem or “program”. Agents can be employees or contractors of theprogram provider, or other companies and organizations that partner withthe program provider to provide these services themselves. Agents may befound in every facet of a typical economy, and may include largeretailers, mobile network operators (MNO) airtime sales agents, gasstations, kiosks, or other places of business.

The mobile wallet platform includes a mobile wallet application, webinterface or some other type of functionality that allows the user tointeract with the mFS platform using their mobile device. The mobilewallet application may include a subscriber identity module (SIM)application, an Unstructured Supplementary Service Data (USSD)application, a smartphone application, a web application, a mobile webapplication, a Wireless Application Protocol (WAP) application, a Java 2Platform, Micro Edition (J2ME) application, a tablet application or anyother type of application or interface that provides tools for the agentto register, activate, and offer other services to the mFS subscriber.

As used herein, a mobile wallet application is a mobile walletapplication installed on a SIM card. A USSD application is anapplication that implements USSD for various functionality includingprepaid callback service, location-based content services, menu-basedinformation services and other mobile wallet platform services. A webapplication is one that implements or uses the internet to providemobile wallet platform functionality. A mobile web application issimilar to a web application, but is tailored for mobile devices. A WAPapplication is one that uses the wireless application protocol tocommunicate with the mobile wallet platform to provide the platform'sfunctionality. A J2ME application is an application developed in Javaand is designed to provide mobile wallet functionality on a variety ofdifferent hardware. A tablet application is an application specificallydesigned for a touchscreen-based tablet that provides mobile walletplatform functionality for tablet devices, and as part of configuringthe phone on the network. Any of these applications (or any combinationthereof) may be provided on the user's mobile device. This functionalitycan also be made available on a retail point of sale (POS) system or website.

The term “agent administrator” refers to an individual with mFS programtools and training to administrate the allocation of funds to agentbranches (e.g. retail locations). As agents perform mFS transactionswith subscribers, such as depositing and withdrawing money, the agentsare adding and removing money from their own accounts. If there areinsufficient funds in the agent's account to complete a transaction,additional money will need to be transferred from the agent company'smaster account to that agent branch account to cover that transaction.An agent administrator is responsible for these funds transfers. Any ofthe applications referred to above may be configured to provide toolsused by the agent administrator to view the agent company balance, viewthe agent branch balances, and transfer funds into and out of agentbranch mobile wallets. This functionality can also be made available ona website for easier access.

The term “agent administrator mobile wallet application” refers to asoftware program or application installed on the agent administrator'sterminal in the agent administrator's mobile device (such as a mobilephone or tablet). This software application provides the agentadministrator the ability to securely perform agent administratorfunctions such as querying the agent company account balance ortransferring funds into and out of agent branch accounts. The agentadministrator's mobile wallet application may be installed on a globalsystem for mobile communications (GSM) SIM card (or on any other type ofSIM card), and may be accessed using a GSM mobile phone. The agentadministrator's application may also be installed on a code divisionmultiple access (CDMA) mobile phone, a 3G, 4G, 4G LTE (Long TermEvolution) or other wireless carrier standard. The application may,additionally or alternatively, be installed directly on the agentadministrator's mobile device. The application communicates with the mFStransaction system using binary and/or text short message service (SMS)messages. A wireless service provider or MNO provides the GSM SMSnetwork infrastructure on which the mFS platform operates.

In some embodiments, the mFS platform application may utilize tripledata encryption standard (3DES) encryption (or some other type ofencryption), encrypted message signing, and password security on some orall of its communications with the mFS transaction system in order toensure that the transactions are properly secured and authenticated.

The term “agent branch” refers to any location where an agent providessupport for subscriber services of the mFS platform. Funds are allocatedby the agent administrator from the agent company's main account to eachagent branch to fund the subscriber mFS functions such as depositing orwithdrawing cash, in-store purchases, bill payments, prepaid airtimetop-ups and money transfers. In some cases, multiple agents may work ina single branch. However, at least in some cases, monetary funds areallocated to from the agent company's main account on a per branchbasis.

The term “agent branch account balance” refers to the amount of moneyresiding in a particular agent branch account at a given time. Funds canbe deposited into the branch account by the agent administrator, or thefunds can come from participating in subscriber mFS transactions such asdepositing or withdrawing cash from the subscriber's mobile walletaccounts, or making retail purchases with the mobile wallet.

Each agent branch is to maintain a balance in their branch account. Thisapplies more strongly in countries where mFS program and financialservices infrastructure is still developing. In cases where real-timeprocessing of financial transactions including card processing is notpractical, subscribers leverage the applications on their mobile phonesto submit transactions and conduct business with retailers, businesses,and other subscribers. The mFS platform manages the balance of mobilewallet accounts for each subscriber as value is transferred from onemobile wallet to another (e.g. from a subscriber's mobile wallet to anagent's mobile wallet in payment for goods or services). This value isreferred to herein as “eMoney”.

As subscribers conduct business with mFS agents, they deposit orwithdraw cash from their mobile wallet accounts. Virtual or eMoneycredits are transferred between the subscriber's mobile wallet accountand the agent branch's account as a form of currency to support thetransaction. As agents accept cash into their cash register by mFSsubscribers, they transfer the equivalent amount of eMoney credits intothe mFS subscriber's mobile wallet account. For instance, if an mFSsubscriber gives an mFS agent $10 to deposit into the subscriber'smobile wallet account, the agent would place the cash into his registerand transfer $10 from the agent branch's eMoney account into thesubscriber's mobile wallet account. While the agent acquired $10 in hisregister, he transferred out $10 of eMoney credits from his brancheMoney account.

In some embodiments, in countries with more developed economies, it maybe beneficial to use program-issued pre-paid debit cards, pre-paidaccess accounts, stored value accounts or gift cards to conduct businessalong with the added convenience of card processing networks such asCirrus, STAR, or Visa for POS and automated teller machine (ATM)functionality. Agents, particularly those in retail outlets and kiosks,can still support subscribers with deposits, withdrawals, and othertransfers, but in this case bank external card processors manage themobile wallet and branch account balances and provide the real-timetransfer of funds.

The term “agent branch ledger” refers to a written (or electronic)ledger maintained by the mFS platform. Agent branch transactions areperformed on the agent's and subscriber's mobile phones where anelectronic record of the transaction is generated and stored on the mFSplatform. These electronic transactions are then reconciled with agentbranch ledgers to ensure the security and integrity of the transaction.Agent branch ledgers are printed or electronic transaction logs that aredistributed to the agent branch locations in hard copy form to serve asa backup record to the electronic transactions.

The term “agent company” refers to a business that registers toparticipate in the mFS program as a partner of the mFS program provideror owner. The agent company has one or more agent branches which conductmFS business with mFS program subscribers. In some cases, the agentcompany may be referred to as a distributor or retailer.

The term “agent company account balance” refers to the sum of the fundsdeposited at a “partner bank” (defined below) by the agent company tofund the agent company's daily transactions. The funds in the agentcompany account are then distributed to agent branches by the agentcompany's agent administrator to conduct everyday business such asaccepting cash deposits and cash withdrawals from mFS subscribers. Thisbalance is sometimes referred to as the “agent company float”.

An “agent manager” is a supervisor of company agents for a givencompany. The agent manager has the training and tools to create, deleteor modify agent accounts for a company, as well as monitor thetransactions performed by agents. The agent manager may have a specialapplication or an increased level of rights to access applicationsfeatures not available to other users. The special application is aprogram installed on the agent manager's terminal. This applicationprovides the agent manager the ability to securely perform agent managerfunctions such as registering and activating new agent accounts.

The mFS agent manager application may be installed on any terminal ordevice. It communicates with the mFS platform using binary and/or textSMS messages. A wireless service provider or MNO provides the GSM SMSnetwork infrastructure on which the mFS platform operates. The mFSplatform mobile wallet applications may utilize 3DES encryption (or anyother type of encryption), encrypted message signing, and passwordsecurity on some or all of its communications with the mFS platform inorder to ensure that the transactions are properly secured andauthenticated.

The term “agent application” refers to an application that provides allthe tools necessary for an agent to register, activate, and offer otherservices to the mFS subscriber. The agent application is a programinstalled on the agent's SIM card or otherwise installed in the agent'smobile device's memory. This application provides the agent the abilityto securely perform agent functions such as registering and activatingnew subscribers and depositing and withdrawing funds from mobile walletaccounts. The mFS agent application may be installed on a GSM SIM cardor mobile phone and may be accessed using a GSM or CDMA mobile phone. Awireless service provider or MNO provides the data and SMS networkinfrastructure on which the mFS platform operates.

The terms “mFS platform”, “mobile wallet platform” and “monetarytransaction system” refer to an overall platform or ecosystem ofdifferent components that work together to provide the various functionsdescribed herein on a global scale. At least some of the various logiccomponents include the following: the application. The “mobile walletapplication” or “mFS application” manages the processing of incomingtransactions regardless of their source. The application handlesend-user authentication, transaction processing, subscriber profilemanagement, and further manages interactions between the variousplatform components.

The mFS platform further includes a transaction processor. Thiscomponent is used when the mFS application is implemented in a countrywhere real-time processing of financial transactions is not practical(or not possible). The transaction processor manages the balance ofmobile wallet accounts, agent accounts, and the accounts of any otherprogram participant. The transaction processor handles balanceinquiries, credits, debits, and transaction roll-backs.

The mFS platform further includes a rules engine that manages andapplies the rules and policy that are defined for transactions as theyare processed on the mFS platform. Rules impact transaction fees,limits, velocity limits, and commissions as well as program actor rolesand permissions. Rules can be customized for each implementation. ThemFS platform also includes an integration interface that manages theintegration and interaction between external systems (i.e. external tothe mFS platform) and the mFS platform. Connectivity to the wirelessservice provider's pre-paid airtime billing platform and the programpartner bank, for example, are managed by the integration interface.

The mFS platform further includes a transaction database that stores thedata that supports the mFS platform. This includes subscriber profilesand subscription data, transaction data and logs, and applicationconfiguration and run-time data, among other types of data. Anothercomponent of the mFS platform is a handset support service thatinterfaces with the wireless service provider's SMS network to allowcommunication between the mobile wallet applications and the back-officesystems via SMS messaging or some other form of data transfer. Stillfurther, another component of the mFS platform is a web component thatprovides a web interface to the mFS program participants that allows thesubscriber to perform the same functions in the web interface that theywould have available through their applications.

The term “bill pay company” refers to a business that signs-up toparticipate in the mFS transaction system. As a participant in the mFStransaction system, the company accepts payment from mFS mobile walletaccounts, either in the form of eMoney or through periodic settlements.

At least in some embodiments, financial transactions that take place inthe mFS mobile wallet platform are funded through pre-paid mobile walletaccounts. Mobile wallet platform subscribers can deposit cash into theirmobile wallet account through a process referred to herein as ‘cash-in’.The cash-in process is supported by mFS agents at agent branchlocations. The agent accepts the cash from the subscriber and transfersthe equivalent amount of eMoney to the subscriber's mobile walletaccount. This process is similar to withdrawing cash from a bankaccount.

As mentioned above, in some embodiments, financial transactions thattake place in the mobile wallet platform are funded through pre-paidmobile wallet accounts. Mobile wallet platform subscribers can withdrawcash from their mobile wallet account through a process known as“cash-out”. The cash-out process is supported by mFS agents at agentbranch locations. The subscriber transfers eMoney from their mobilewallet account to the agent's eMoney account. Upon receiving the eMoney,the agent gives the subscriber cash from their branch cash register.

Accounts managed on the mFS platform by the mFS eMoney transactionprocessor maintain the mobile wallet balance of mFS program participantsincluding subscribers, agent branches, agent companies, and non-agentcompanies. eMoney is moved between Mobile Wallet accounts by thetransaction processor based on mFS transaction processing. Only whentransactions involving cash (i.e. depositing or withdrawing funds fromthe mFS program) or the movement of money from mFS participants tonon-mFS program participants are funds moved from the master bankaccounts.

As subscribers, agents, and other mFS program participants conductbusiness in the mFS program, value is transferred from one account tothe next as payment for services rendered or goods purchased. This valuecan be in the form of real currency or the electronic representationreferred to herein as eMoney.

Among other situations, eMoney is used in mFS implementations where thereal-time processing of financial transactions including card processingis not practical. The mFS platform utilizes an internal transactionprocessor for managing the real-time balance of mobile wallet and agentaccounts as value (eMoney) is transferred from one mobile wallet toanother in payment for services.

As subscribers conduct business with mFS agents, they deposit orwithdraw cash from their mobile wallet accounts. Virtual or eMoneycredits are transferred between the subscriber mobile wallet accountsand the agent branch accounts as a form of currency to support thetransaction. As agents accept cash into their cash register by mFSsubscribers, they transfer the equivalent amount of eMoney credits intothe mFS subscriber's mobile wallet account. For example, if an mFSsubscriber gives an mFS agent $10 to deposit into the subscriber'smobile wallet account, the agent would place the cash into his or herregister, and transfer $10 from the agent branch eMoney account into thesubscriber's mobile wallet account. While the agent acquired $10 in hisor her register, the agent transferred-out $10 of eMoney credits fromhis or her branch eMoney account. This will be explained in greaterdetail below.

In some embodiments, employers may wish to participate in the mFSprogram by allowing the direct deposit of paychecks into subscribers'mobile wallet accounts. Accordingly, each payday, the user's pay isdirectly transferred to the subscribers' mobile wallet.

The term “know your customer” or “KYC” refers to information collectedabout an individual that identifies that individual. Such information isused to establish a mobile wallet account with the mobile walletplatform. Regulatory requirements in some countries require that newbank account creation must be preceded by a display of a validgovernment ID. These KYC regulations may vary from country to country.Accordingly, different KYC information may be requested from subscribersin different countries in order to establish a mobile wallet account.

The term micro-finance institution (MFI) refers to a lender that issuessmall loans. MFIs participating in the mFS program lend to mFS programsubscribers and accept loan repayment either in the form of eMoney orsettlements with the mFS platform provider.

The term “mFS program”, like the term “mFS platform” refers to theecosystem of companies, service providers, and subscribers thatparticipate in providing mobile financial services to their customers.In some embodiments, there may be one mFS program implementation percountry. Each program includes a program owner and operator, a programplatform, a partner wireless services provider or MNO, and a partnerbank.

The term “mFS program master account” refers to a bank accountmaintained by the mFS program partner bank to provide funds and floatfor the operation of the mFS platform. Depending on the type of mFSimplementation, the master account can include sub-accounts for each ofthe agent branches and subscriber mobile wallets, giving the bankvisibility into all transactions on a per-user basis. The mFS platformcan also manage the balance of sub-accounts and interact with the bank'smaster account when funds need to be deposited or withdrawn from theaccount.

The term mobile network operator (MNO) refers to a provider of mobilephone service including basic voice, SMS, unstructured supplementaryservice data (USSD) and data service, and may also be referred to as a“wireless service provider”.

The term “mobile wallet” or “mobile wallet account” refers to a storedvalue account or prepaid access account (PPA) that allows the owner (or“subscriber”) to pay for goods and services on the mFS platform from hisor her mobile wallet account. When the mFS eMoney transaction processoris used, the mobile wallet balance is maintained by the mFS platform andvalue is exchanged within the mFS program as eMoney. When the mFSplatform is integrated to an external card processor, the mobile walletutilizes funds from the subscriber's prepaid debit card and bank accountto exchange value on the mFS platform.

The term “non-agent company” refers to a mFS program participant whoaccepts payments from mFS subscribers but does not provide the sameservices as mFS agent companies. Payment is accepted either in the formof eMoney or through periodic settlements with the mFS platformprovider. Examples of non-agent companies include bill pay providers andmicro-finance lenders.

The term “non-mFS subscribers” refers to unregistered users thatparticipates in various use cases in the mFS program. Non-mFSsubscribers can send money to or receive money from mFS subscribersthrough interaction with the mFS program agents or with internationalremittance providers.

The term “partner bank” refers to the primary bank participating in themFS program. The partner bank is responsible for holding the mFS programmaster accounts that hold the funds for all mFS services andtransactions. A “PIN” refers to a numeric password that may be requiredto perform a transaction via the mobile wallet application. A“transaction processor” refers to an application or service that managesthe mFS program account balances. The transaction processor determinesthe amount of funds or eMoney is in a particular account at any giventime, and manages account balances. Mobile transaction system requeststo credit, debit, or view the balance of a particular mobile wallet orprogram account are handled by the transaction processor (in conjunctionwith other components of the mobile wallet platform).

The term “sub-accounts” refers to accounts that are maintained withinthe mFS platform or by an external card processor. A partner bank mayelect to maintain a separate bank account for each subscriber and/oragent branch, or a single master account may be established thatcontains the funds for all of the subscriber mobile wallet and agentbranch accounts (at least within a country or other geographicalregion). The balance of each individual user may be managed by the mFStransaction processor.

When using a master account, the bank is involved only in transactionsthat require the movement of funds external to the mFS program. Forexample, subscriber cash-in and cash-out transactions involve theaddition and removal of cash from the mFS program and would consequentlyinclude a deposit or withdrawal from the master account. Retailpurchases from participating mFS program retailers or the exchange offunds between mFS subscribers results in no net change in the mFSprogram balance and thus do not require involvement by the partner bank.

The term “subscriber” refers to a participant of the mFS mobile walletplatform. The subscriber maintains a mobile wallet balance and performstransactions using the mFS application. An “unbanked subscriber” is asubscriber that does not have (or does not have access to) a bankaccount or credit union account. The application or “mobile walletapplication” provides mobile wallet functionality to the (unbanked)subscriber. The mobile wallet application is installed on a mobiledevice in the device's memory, on a SIM card (such as a GSM SIM card) oris otherwise accessible to the mobile device. The mobile walletapplication provides the subscriber the ability to securely performsubscriber functions such as making retail purchases, paying bills, ortransferring money to other mFS subscribers and non-subscribers. Themobile wallet application communicates with the mFS platform usingbinary and text SMS messages, among other forms of wirelesscommunication. A wireless service provider or MNO provides the GSMnetwork infrastructure on which the mFS platform operates.

FIG. 1 illustrates an example system architecture for a mobile walletplatform. Integration tier 101 is configured to manage mobile walletsessions and maintain integrity of financial transactions. Integrationtier 101 can also include a communication (e.g., Web services) APIand/or other communication mechanisms to accept messages from channels111. Other mechanisms include, but are not limited to: InternationalStandards Organization (“ISO”) 8583 for Point of Sale (“POS”) andAutomated Teller Machines (“ATM”) devices and Advanced Message QueuingProtocol (“AMQP”) for queue based interfaces. Each of channels 111 canbe integrated to one or more mechanisms for sending messages tointegration tier 101. Notification services 102 is configured to sendvarious notifications through different notification channels 112, suchas, for example, Short Message Peer-to-Peer (“SSMP”) for Short MessagingService (“SMS”) and Simple Mail Transfer Protocol (“SMTP”) for emails.Notification services 102 can be configured through a web services API.

Service connectors 103 are a set of connectors configure to connect to3rd party systems 113. Each connector can be a separate module intendedto integrate an external service to the system architecture. Businessprocess services 104 are configured to implement business workflows,including executing financial transactions, auditing financialtransactions, invoking third-party services, handling errors, andlogging platform objects. Payment handler 105 is configured to wrap APIsof different payment processors, such as, for example, banking accounts,credit/debit cards or processor 121. Payment handler 105 exposes acommon API to facilitate interactions with many different kinds ofpayment processors.

Security services 106 are configured to perform subscriberauthentication. Authorization services 107 are configured to performclient authorization, such as, for example, using a database-basedAccess Control List (“ACL”) table.

Database 108 is configured to manage customer accounts (e.g., storingcustomer accounts and properties), manage company accounts (e.g.,storing company accounts and properties), manage transaction histories(e.g., storing financial transaction details), store customer profiles,storing dictionaries used by the mobile wallet platform, such as, forexample, countries, currencies, etc., and managing money containers.Rules engine 109 is configured to gather financial transactionstatistics and uses the statistics to provide transaction properties,such as, for example, fees and bonuses. Rules engine 109 is alsoconfigured to enforce business constraints, such as, for example,transactions and platform license constraints.

Name matching engine 110 is configured to match different objectsaccording to specified configuration rules. Matching engine 110 can beuse to find similarities between names, addresses, etc. Transactionprocessor 121 is configured to manage financial accounts andtransactions. The transaction processor 121 can be used to hold, load,withdraw and deposit funds to mobile wallet accounts. Transactionprocessor 121 can also be used as a common interface to a third partyprocessor system. When used as a common interface, financial operationsmay be delegated to the external processor. A Clearing House subsystemof transaction processor 121 can be used to exchange the financialinformation with a bank.

Components of a mobile wallet platform can be connected to one anotherover (or be part of) a system bus and/or a network. Networks can includea Local Area Network (“LAN”), a Wide Area Network (“WAN”), and even theInternet. Accordingly, components of the mobile wallet platform can be“in the cloud”. As such, mobile wallet platform components as well asany other connected computer systems and their components, can createmessage related data and exchange message related data (e.g., InternetProtocol (“IP”) datagrams and other higher layer protocols that utilizeIP datagrams, such as, Transmission Control Protocol (“TCP”), HypertextTransfer Protocol (“HTTP”), Simple Mail Transfer Protocol (“SMTP”),etc.) over the system bus and/or network.

The components depicted in FIG. 1 can interoperate to provide a numberof financial and other services including but not limited to enrolling acustomer for a mobile wallet, adding a stored value account (eitherhosted by a mobile wallet platform or a third party), adding a bank orcredit union account to a mobile wallet, adding a debit or credit cardaccount to a mobile wallet, depositing funds in a mobile wallet,withdrawing funds from a mobile wallet, paying bills from a mobilewallet, topping up a prepaid mobile account through a mobile wallet,transferring funds through a mobile wallet (nationally orinternationally), making in-store purchases using a mobile wallet, andvarious other tasks as described herein below. These services will bedescribed in greater detail below with regard to system FIGS. 1 and 2,as well as FIGS. 3-19B.

FIG. 2 depicts a monetary transaction system 200 similar to thatdescribed in FIG. 1. The monetary transaction system 200 may provide amore simplified system structure in which each of the above services maybe provided. The system includes a subscriber 205. The subscriber mayhave access to a bank account, or may be an unbanked subscriber. Thesubscriber has a profile 211 with the monetary transaction system 210.The profile includes the subscriber's KYC information, as well as anyassociated bank accounts, credit union accounts, bill pay accounts orother accounts. The subscriber has (or has access to) a mobile device206 such as a phone or tablet. The mobile device runs the mobile walletapplication (or mobile wallet application) 207.

The subscriber can indicate, using the mobile application 207 whichtransaction or other action he or she would like to perform. Theindicated transaction 208 is sent to the mobile wallet platform 210 tobe carried out by the platform. The transaction processor 216 (which maybe similar to or the same as transaction processor 121 of FIG. 1)performs the transaction(s) specified by the (unbanked) subscriber 205.The transaction processor may implement various other components toperform the transaction including memory 217, (wireless) communicationmodule 215, rules engine 210 and/or transaction database 225.

Performing the specified transactions may include communicating with themonetary transaction database 225 to determine whether the transactionis permissible based on data indicated in the unbanked subscriber'sprofile (for instance, whether the subscriber has enough eMoney in hisor her stored value account, or has enough money in his or her bankaccount). Rules engine 220 may also be consulted to determine whetherthe subscriber has exceeded a specified number of allowed transactions.Then, if funds are available, and the transaction is otherwisepermissible, the monetary transaction system can transfer money oreMoney 221 to or from an entity such as a user or agent (e.g. entity222) to or from an establishment such as a retail store or agent company(e.g. entity 223).

In some cases, the monetary transaction system 210 application providesa web interface that allows subscribers to perform the same functionsprovided by the monetary transaction system application. For instance,mobile wallet application 207 may provide a web interface that allows auser to enroll for a mobile wallet. The web interface (or the mobilewallet application itself) receives a subscriber-initiated transactionover one of a plurality of channels (111 from FIG. 1) connected to themonetary transaction system 210. The web interface or mobile walletapplication may prompt for and receive enrollment information (e.g. KYCinformation) for the (unbanked) subscriber 205 over at least one of theplurality of channels (e.g. web, point-of-sale (POS), interactive voiceresponse (IVR, etc.). The web interface or mobile wallet application maythen send activation instructions over the same or a different channelto activate the (unbanked) subscriber 205 and create a subscriberaccount for the (unbanked) subscriber.

Once the subscriber has an account, the monetary transaction systemgenerates a corresponding mobile wallet for the unbanked subscriber(available via the web interface and/or the mobile wallet application.The system then presents the (unbanked) subscriber's account dataassociated with the mobile wallet and/or a notification indicating thatenrollment was successful to the subscriber. Accordingly, the mobilewallet application or the web interface may be used to provide userenrollment functionality. It should also be understood that either themobile wallet application or the web interface may be used to providesubstantially all of the mobile wallet functionality described herein.

It should also be noted that the mobile device 206 may be any type ofplan-based phone or tablet, or prepaid phone or tablet. Manysubscribers, such as unbanked subscribers, may primarily use prepaidphones. The mobile wallet application 207 may be installed on bothplan-based phones and prepaid phones. The mobile wallet application maybe installed on the device's SIM card, or on the device's main memory.Accordingly, the monetary transaction system 200 may be accessed andused via substantially any type of plan-based or prepaid mobile device.

FIG. 3 shows three different graphics (301-303) and corresponding methodsteps (310-370) that illustrate an unbanked subscriber making a depositusing a mobile wallet (and, by extension, using the mobile wallettransaction system 210). In at least some of the embodiments describedbelow, the actions of each participant are shown and described. Thiswill also, at least in some embodiments, include an illustration ofmoney flow throughout the mobile wallet transaction system. In thegraphics, various terms are used as follows: $C=Cash Balance and$E=Electronic Money (eMoney) Balance.

At graphic 301, it is assumed that the unbanked subscriber (e.g. 205)has already registered and activated an eMoney account at an agentbranch location (e.g. a retail store, gas station, or other locationthat has registered to be an agent branch). To deposit cash in order toget eMoney credit, the subscriber informs the agent manager or agentthat they want to deposit a certain amount of cash (in 301). The agentmanager/agent takes the cash and notifies the mobile wallet transactionsystem of the deposit using their agent manager or agent application(302). The transaction system 210 then credits the subscriber's eMoneyaccount (303). Accordingly, any location that has registered to accepteMoney payments from subscribers' mobile wallets can also accept cashdeposits. The agent branch's eMoney balance is reduced because theiractual money balance was increased by the amount of the deposit. Thesubscriber's mobile wallet account is credited with eMoney in the amountof the deposit. In this manner, a subscriber can deposit cash into theirmobile wallet account (in the form of eMoney) at any retail location orother agent branch location.

Thus, the agent manager receives the physical cash deposit into thesubscriber's eMoney account via the agent manager or agent'sapplication. The subscriber gives cash to agent manager or agent, andthe mFS platform processes the request, updates the agent branch andsubscriber's eMoney balances, logs the transaction, and sends details(such as eMoney account balances, transaction logs, etc.) to bankspecified by the mobile wallet platform. These details may be sentinstantaneously as transactions occur, or in batches at pre-determinedintervals.

In one embodiment, the monetary transaction system 210 of FIG. 2 isimplemented to deposit funds at an agent branch using a mobile wallet.The monetary transaction system 210 receives communication from an agentbranch over one of a plurality of channels (e.g. 111) connected to themonetary transaction system (step 310). The agent communicationindicates that the unbanked subscriber 205 desires to deposit aspecified amount of funds into the unbanked subscriber's mobile walletaccount. The transaction processor 216 then validates the status of theunbanked subscriber's mobile wallet account (step 320) and determines ifthe agent branch is authorized to receive deposited money (i.e.determine if it has pre-registered as an official agent branch) (step330).

The monetary transaction system may then use rules engine 220 to performa limit check (to determine whether sufficient funds are available)and/or a velocity check (to determine whether the user has exceeded aspecified number of (hourly, daily, or weekly) transactions) on theunbanked subscriber's mobile wallet account (step 340). The transactionsystem then credits the unbanked subscriber's mobile wallet account withthe specified amount of funds (step 350) and returns a notification tothe agent branch confirming the deposit (step 360) and returns anothernotification to the subscriber notifying the subscriber that thespecified amount of funds was deposited in the their mobile walletaccount (step 370). Any of channels 111 may be used to perform thesecommunications.

FIG. 4 shows three different graphics (401-403) and corresponding methodsteps (410-490) that illustrate an unbanked subscriber making awithdrawal using a mobile wallet (and, by extension, using the mobilewallet transaction system 210). As above, the terms in the graphicsinclude “$C” representing cash balance and “$E” representing eMoneybalance.

To withdraw cash at an agent branch, a subscriber submits a withdrawalrequest using their application (401). The subscriber may also enterinformation about the agent branch (e.g. name of establishment, name ofagent, location or other information) that allows the monetarytransaction system 210 to identify the agent branch. The transactionprocessor 216 may then determine whether the unbanked subscriber hasenough eMoney to withdraw the requested amount. If he or she does haveenough eMoney, then the subscriber's eMoney is deducted and that amountis transferred to the agent branch's eMoney account (402). Then, theagent branch gives the subscriber the requested amount of cash (403). Inthis manner, any entity that has established itself as an agent branch(including retail stores, gas stations, service providers, etc.) canprovide cash withdrawal to a mobile wallet subscriber (whether banked orunbanked). The agent's or agent manager's role is to verify thewithdrawal request (e.g. via SMS on the agent's or agent manager'sphone) and gives the cash to subscriber. The subscriber requests cashwithdrawal from agent branch's eMoney account via the application, andreceives physical cash from agent manager/agent. The mobile walletplatform processes the request, updates the agent branch's andsubscriber's eMoney balances, logs the transaction, and sendstransaction details to a specified bank at pre-determined intervals.

In one embodiment, the monetary transaction system 210 is implemented towithdraw funds at an agent branch using a mobile wallet. Thecommunication module 215 receives a communication from an unbankedsubscriber over one of a plurality of channels 111 connected to themonetary transaction system 210 (step 410). The communication indicatesthat the unbanked subscriber 205 desires to withdraw a specified amountof funds from the unbanked subscriber's mobile wallet account at theagent branch. The monetary transaction system 210 validates the statusof the unbanked subscriber's mobile wallet account (step 420) anddetermines if the balance of the unbanked subscriber's mobile walletaccount is sufficient to accommodate the requested withdrawal for thespecified amount of funds (step 430).

The transaction processor 216 performs one or more of a limit check (toverify sufficient funds) and a velocity check (to verify the subscriberhasn't exceeded specified transfer limits) on the unbanked subscriber'smobile wallet account (step 440). The monetary transaction system 210then returns a secure, perishable withdrawal code to the subscriber 205over at least one of the plurality of channels 111 connected to themonetary transaction system (step 450). The monetary transaction system210 receives subsequent agent branch communication over at least one ofthe plurality of channels connected to the monetary transaction systemindicating that the withdrawal code has been presented to the agentbranch (step 460). The monetary transaction system 210 then debits theunbanked subscriber's mobile wallet account by the specified amount offunds (step 470), returns a notification to the agent branch confirmingthe withdrawal (step 480) and notifies the subscriber that the specifiedamount of funds was withdrawn from the unbanked subscriber's mobilewallet account over at least one of the channels 111 connected to themonetary transaction system (step 490). Accordingly, the monetarytransaction system 210 may be used to allow subscribers to withdraw cashusing their mobile wallet applications at any store or other entityregistered as an agent branch.

FIG. 5A depicts a subscriber-to-subscriber eMoney transfer. To performsuch a transfer, subscriber A (501) enters some type of identificationinformation identifying subscriber B (e.g. subscriber B's phone number)and an amount of money he or she wishes to transfer. The transactionprocessor 216 of the monetary transaction system 210 determines if thereare sufficient funds to complete the transfer. If sufficient funds areavailable, the monetary transaction system 210 decrements subscriber A'saccount and credits subscriber B's account (502). The system then sendssome kind of notification (e.g. SMS) to subscriber B indicating that acertain amount of money was transferred to their account. Subscriber Amay also receive a notification that the transfer was successful.Accordingly, eMoney may be transferred between two mFS platformsubscribers, one or both of which may be unbanked. The monetarytransaction system 210 processes the subscribers' requests, updates thesubscribers' eMoney balances, logs the transactions, and sendstransaction information to a specified bank when needed.

FIG. 5B illustrates a subscriber-to-non-subscriber eMoney transfer. Ingraphic 505, subscriber A wishes to send eMoney to another individualthat is not a subscriber to the mFS platform. The transaction isinitiated in the same fashion as the subscriber-to-subscriber transferscenario. However, since non-subscriber B does not have a mobile walletaccount, the monetary transaction system 210 cannot credit them witheMoney. Instead, the monetary transaction system 210 sends anotification (e.g. via SMS) to non-subscriber B with instructions forhow to pick-up the transferred money, along with an authorization code(506). The monetary transaction system 210 puts a hold on subscriber A'saccount for the amount transferred. Subscriber B then has a specifiednumber of days to pick up the cash before the hold expires and theamount is credited back to subscriber A's eMoney account by the monetarytransaction system 210.

When non-subscriber B goes to pick up the money at an agent branch, theagent branch's manager or agent verifies the authorization code via anagent manager or agent mobile wallet application (that, in turn,accesses the mFS platform). Once the transfer has been validated, theagent gives the cash to non-subscriber B. The agent branch's mFS accountis credited with the transfer amount (507) and the user leaves with thecash in hand (508). The mFS platform processes the transfer request,updates subscriber A's eMoney balance, logs the transaction, and sendstransaction details to a platform-specified bank.

FIG. 6A illustrates a subscriber-to-subscriber international eMoneytransfer. This embodiment is, at least in some respects, similar tosending eMoney to an mFS subscriber domestically. In this case themonetary transaction system 210 leverages one or more existinginternational money transfer organizations or “remittance companies”such as MoneyGram®. In some embodiments, MoneyGram® is pre-integrated tothe monetary transaction system 210, but other international moneytransfer organizations may also be used. Still further, at least in someembodiments, subscriber B may need to have an eMoney account with aforeign mFS program that is also affiliated with MoneyGram® or anotherinternational money transfer organization.

In FIG. 6A, subscriber A initiates the international eMoney transfer at601, the international money transfer organization (e.g. MoneyGram®)transfers the eMoney to subscriber B at 602 and subscriber B's eMoneybalance is increased by the transferred amount. Thus, subscriber Arequests to send eMoney from his or her eMoney account via the mobilewallet application. The eMoney is transferred using an internationalmoney transfer organization, and subscriber B receives a notification(that may, for example, include a reference number, among otherinformation) that their eMoney balance has increased by the transferamount. The monetary transfer system 210 processes subscriber A'srequest, updates subscriber A's and subscriber B's eMoney balances, logsthe transaction, and send transaction details to a mFSplatform-specified bank.

FIG. 6B illustrates a subscriber-to-non-subscriber international eMoneytransfer. In this illustration, subscriber A wishes to send cash tosubscriber B who is not an mFS program subscriber. Similar to thescenario described in FIG. 6A, the monetary transaction system 210leverages various international money transfer organizations orremittance companies such as MoneyGram® to transfer the eMoney.Subscriber A initiates a typical eMoney transfer at 605 by providingnon-subscriber B's identification information, as well as the amount tobe transferred. The Monetary transaction system 210 recognizes theeMoney transfer is not destined for a domestic phone number and routesthe request to the international money transfer organization (e.g.MoneyGram®) (606).

The international money transfer organization sends non-subscriber B anotification (e.g. via SMS) with instructions for how and where to pickup the money (in embodiments where MoneyGram® transfers the eMoney, thenotification may include a MoneyGram® reference number (MGRN)) (607).Non-subscriber B can then show the MGRN to an agent at an agent branch(608) and then receive the cash (609). The monetary transaction system210 then decrements subscriber A's eMoney account for the transferredamount. The monetary transfer system 210 thus processes subscriber A'stransfer request, updates subscriber A's eMoney balance, logs thetransaction, and sends transaction detail to a platform-specified bank.It should also be noted that an mFS subscriber may also receive money ina foreign country from either a subscriber or a non-subscriber in asimilar manner.

FIG. 7 illustrates a subscriber purchasing airtime using a mobilewallet.

Mobile wallet platform subscribers may buy airtime by using their mobilewallet application 207. The monetary transaction system 210 will reloadtheir airtime account within the mobile network operator's (MNO's)systems. The subscriber requests to purchase airtime by entering therequest via the mobile wallet application or via a mobile wallet webinterface. The monetary transaction system 210 then decrements thesubscriber's eMoney account (701), while crediting the mFS platform'seMoney account (702). The purchased airtime is then added to thesubscriber's airtime balance (703). The monetary transaction system 210processes the subscriber's request, updates the subscriber's eMoneybalances as well as its own eMoney balance, logs the transaction, andsends transaction detail to a mFS platform-specified bank.

In one embodiment, the monetary transaction system 210 is implemented totop up a prepaid mobile account from a mobile wallet. The communicationmodule 215 of the monetary transaction system 210 receives a subscribercommunication over one of a plurality of channels 111 connected to themonetary transaction system (step 710). The subscriber communicationindicates that an unbanked subscriber 205 desires to top up a prepaidmobile account by a specified amount using a specified payment methodfrom the unbanked subscriber's mobile wallet. The transaction processor216 validates the status of the selected payment method (step 720) andperforms a limit check and/or a velocity check on the selected paymentmethod (step 730). The monetary transaction system 210 then debits thespecified payment method by the specified amount of funds (step 740) andprocesses the mobile top-up via a billing system integrator and/or anaggregator (step 750), and notifies the subscriber that the prepaidmobile account was topped up over at least one of the channels connectedto the monetary transaction system (step 760).

FIG. 8 illustrates an embodiment where a mFS subscriber pays a billusing a mobile wallet. At least in some embodiments, the company thatthe subscriber wishes to pay needs to have signed-up to be part of themFS platform. The mFS platform may publish a list of company names thathave registered to be part of the mFS platform. This list of companiesmay include company IDs so that subscribers can know which company ID toenter in their mobile wallet application. Once the company ID is known,the subscriber can pay a bill by entering the company ID and the amountto be paid. The monetary transaction system 210 then decrements thesubscriber's eMoney account (801) and credits the identified company'seMoney account (802). Accordingly, in response to the subscriber'srequest to pay bill via their mobile wallet application, the monetarytransaction system 210 processes the request, updates the bill paycompany's and the subscriber's eMoney balances, logs the transaction,and sends transaction details to the mFS platform-specified bank.

In one embodiment, the monetary transaction system 210 is implemented topay a bill from a mobile wallet. The communications module 215 of themonetary transaction system 215 receives a subscriber communication overa communication channel 111 connected to the monetary transaction system(step 810). The subscriber communication indicates that unbankedsubscriber 205 desires to pay a bill for a specified amount using aspecified payment method from the unbanked subscriber's mobile wallet(e.g. eMoney). The monetary transaction system 210 validates the statusof the selected payment method (step 820) and performs a limit checkand/or a velocity check on the selected payment method to ensure theeMoney transfer is permissible (step 830). The monetary transactionsystem then debits the specified payment method by the specified amountof funds (step 840), processes the bill payment via a direct billerconnection or a bill pay aggregator (step 850), and notifies theunbanked subscriber that the bill was paid using a communication channel(e.g. SMS) connected to the monetary transaction system (step 860).Thus, in this manner, a subscriber may use a mobile wallet to payvarious bills including rent, utility, mortgage, phone, cable, medicaland other bills.

FIG. 9 illustrates a mobile wallet subscriber making a retail purchase.Mobile wallet subscribers can make retail purchases at agent branchesdirectly from their mobile device. Agent branches, as explained above,are retail stores or other entities that have registered with the mFSsystem and are able to accept mobile wallet payments. Accordingly, asubscriber can select the items they wish to purchase, and indicate (viathe mobile wallet application) to the agent branch that they wish to payfor the items. The mobile wallet application then communicates with theagent branch and the monetary transaction system to indicate the priceof the transaction. The monetary transaction system 210 then debits thesubscriber's eMoney account (901) and credits the agent branch's eMoneyaccount (902). The agent branch (and/or the agent manager or agent)receives confirmation that subscriber paid for the purchase. Thesubscriber may also receive a summary of the retail purchase and may beasked to confirm the purchase by entering a PIN. The monetarytransaction system processes the purchase request, updates the agentbranch and subscriber's eMoney balances, logs the transaction, and sendstransaction details to a mFS platform-specified bank.

In one embodiment, the monetary transaction system 210 is implemented tomake a purchase from a mobile wallet. The communications module 215 ofthe monetary transaction system 210 receives a communication from asubscriber over a communication channels 111 (step 910). The subscribercommunication indicates that an unbanked subscriber 205 desires topurchase an item for a specified amount of funds using a specifiedpayment method from the unbanked subscriber's mobile wallet.

The monetary transaction system 210 then returns a secure, perishablepurchase code to the unbanked subscriber over at least one of thechannels connected to the monetary transaction system (step 920) andreceives a subsequent agent branch communication over a channelindicating that the purchase code has been presented to an agent(branch) (step 930). The monetary transaction system 210 validates thestatus of the specified payment method (step 940), determines if thespecified payment method can accommodate a purchase for the specifiedamount (step 950), performs a limit check and/or a velocity check on theselected payment method (960), debits the specified payment method bythe specified amount of funds (970), returns a notification to the agentbranch authorizing the purchase (980) and sends a receipt to theunbanked subscriber over a communication channel. The monetarytransaction system 210 may thus be used to make a retail purchase usinga mobile wallet.

FIG. 10A illustrates a subscriber requesting a micro-loan. Financialinstitutions and potentially other mFS program participants may sign upto become money or eMoney lenders. Mobile wallet subscribers may be ableto use their mobile wallets to request micro-loans from these approvedlenders. The micro-loans are tracked by the monetary transaction system210, and repayment reminders, interest and commissions are managed bythe monetary transaction system. The subscriber requests a micro-loanfrom a lender, indicating the amount in the request, as well as otherinformation such as the repayment date and the commission (i.e. interestrate). Potential lenders then have a chance to counter the loan requestwith their own terms. Once the lender approves the subscriber's request,the lender's eMoney account balance is debited for the specified amount(1001) and the subscriber's eMoney account is credited with therequested amount (1002). The monetary transaction system 210 processesthe micro-loan requests, update the lender and subscriber's eMoneybalances, sets up repayment schedules and reminders, logs thetransaction, and sends transaction detail to a mFS bank. It should alsobe noted that while the term “micro-loan” is used herein, the loan maybe for substantially any amount of money.

Following on the embodiment described in FIG. 10A, FIG. 10B illustratesa subscriber repaying a micro-loan. The subscriber may repay the loanusing functionality provided in the mobile wallet application or in asimilar web interface. Repayments can be made in installments or in fulldepending on the rules of the micro-loan. The subscriber enters theamount they wish to repay and the loan ID. The subscriber's eMoneyaccount is then debited for the specified amount (1005), while thelender's eMoney account is credited the specified amount (1006). Boththe lender and the subscriber may receive confirmation that the loan hasbeen repaid via SMS or some other communication channel. The mFSplatform thus processes the subscriber's micro-loan repayment request,updates lender and subscriber's eMoney balances, updates repaymentschedule and reminders, logs the transaction, and sends transactiondetails to a specified mFS platform bank.

FIG. 11A illustrates a subscriber receiving a direct deposit from anemployer or other entity. Subscribers to the mFS platform have theability to receive any direct deposit into their eMoney account.Subscribers may be asked by their employers to provide accountinformation in order to set up direct deposit. The employer then submitsa direct deposit request using their existing processes (i.e theprocesses they use for a normal checking or savings bank account). Oncethe direct deposit is set up and a payday arrives, the employer's bankaccount is debited for the proper amount (1101) and the employer's mFSaccount is credited with that amount (1102). Then, once the funds havebeen received at the mFS platform bank, the mFS platform bank sweeps theemployers direct deposit balance (1103) into a mFS platform masteraccount (1104) and notifies the mFS platform of each account to beincremented (including the subscriber's mobile wallet (eMoney) account).The subscriber's eMoney account is then credited with the paycheckamount (1105) upon which the eMoney may be used to pay for goods, paybills, top up airtime, transfer to other entities or for cashwithdrawal.

The subscriber does not need to have a bank account to participate indirect deposit. The employer's bank can communicate with the mFSplatform's bank to perform the necessary steps in directly depositingthe subscriber's paycheck in his or her eMoney mobile wallet account.The bank facilitates monetary deposit into the employer's bank accountfor direct deposit and performs an automated sweep of recent depositsfrom the employer's bank account into the mFS platform's master bankaccount. The bank also sends transaction details to the monetarytransaction system 210 including transaction logs. The monetarytransaction system receives a list of eMoney accounts that are to becredited directly from the employer (or bank), processes the list andrequests to establish a direct deposit, updates subscriber's eMoneybalance, log the transaction, and sends transaction details to the mFSplatform bank.

In a similar manner, a subscriber may receive a government welfarepayment directly on their mobile device. FIG. 11B illustrates asubscriber receiving a government social welfare payment directly intotheir eMoney account. In some embodiments, subscribers may need toopt-in and register with the government program for which they choose toreceive the payment via their mobile wallet. Once the funds have beenreceived, the subscriber can use that eMoney for any goods or services,as described above. Once the direct deposit has been established and apayout has been initiated, the government's welfare account deposits themoney (1110) into the government's bank account for welfare payments(1111) and performs an automated sweep of recent deposits from thegovernment's bank account (1112) into the mFS program's master bankaccount (1113). The bank then sends transaction details to the monetarytransaction system 210 regarding the deposit. The subscriber receives anotification that the welfare payment has been credited to their eMoneyaccount (1114). The mFS platform receives an indication of eMoneyaccounts that are to be credited from the government, processes thewelfare payments, updates the subscriber's eMoney balance, logs thetransactions, and sends transaction details to the mFS platform bank.

FIG. 12A illustrates an agent administrator distributing eMoney tovarious recipients. An agent administrator, as explained above, is aperson who acts as an agent company's representative. The agentadministrator deposits, withdraws, and distributes funds into and out ofthe agent company's bank account. When an agent administrator depositscash into an agent company's bank account, it is credited as eMoney tothe agent company's account. In order to provide the agent branches witheMoney, the agent administrator first moves the eMoney from the agentcompany's account (1201) to the branch accounts (1202). This isperformed using the agent administrator's mobile wallet application orportal. In an agent administrator money transfer, the monetarytransaction system 210 processes the administrator's eMoney transferrequest, updates the agent company and agent branch eMoney balances,logs the transaction, and sends transaction details to the mFS platformbank.

FIG. 12B illustrates an agent company deposit. The agent company has aneMoney account in the monetary transaction system 210 that may alsoinclude a corresponding bank account (that may be created automaticallyupon creation of the agent company's eMoney account). After the agentcompany's bank account has been set up, the agent administrator can makedeposits into that account. As FIG. 12B shows, once cash (1205) has beendeposited into the bank account (1206), it is transferred to a mFSplatform master account (1208) that includes all or a part of the mFSplatform's funds. The agent company's bank account is decreased by thedeposit amount (1207), while the agent company's eMoney account balanceis correspondingly increased (1210). At this time, the agent companyaccount is credited with eMoney. The agent company's bank facilitates aphysical cash deposit into the agent company's bank account and performsan automated sweep (1209) of recent deposits from the agent company'sbank account into the mFS platform's master bank account. The agentcompany's bank then sends transaction details to the monetarytransaction system 210. The agent administrator physically delivers thecash (or form of money such as a check or money order) to a bank branchfor deposit. The monetary transfer system receives transaction detailsfrom the agent company's bank about recent transactions (includingdeposits, as shown in FIG. 12B.

FIG. 13 illustrates an agent company withdrawal. To make a cashwithdrawal for an agent company, the agent administrator requests awithdrawal using the agent administrator mobile wallet application. Themonetary transaction system 210 then notifies the bank that a certainamount of eMoney is to be transferred from the master mFS account (1302)to the agent company bank account (1303). When the money is in the agentcompany bank account, the agent administrator can withdraw the cash bytraditional withdrawal means. The mFS master bank receives transactiondetails from the monetary transaction system 210 about recenttransactions (recent withdrawals in this case). The mFS master bankperforms an automated sweep (1304) of the mFS platform's master bankaccount to reflect the recent withdrawal request from agent the agentcompany (1301). The agent company's eMoney account is reduced by theamount of the withdrawal. The agent company also sends transactiondetails to the monetary transaction system 210. The agent administratorcan request withdrawal via the agent administrator mobile walletapplication and physically withdrawal cash (1305) from the agentcompany's bank branch (1306). The mFS platform processes the agentcompany's withdrawal request, updates agent company and agent brancheMoney balances, logs the transaction, and sends transaction details toan mFS platform-specified bank.

Attention will now be turned to embodiments in which subscribers havebank accounts associated with their mobile wallets. The monetarytransaction system 210 provides similar functionality to consumers thathave bank or credit union accounts. Although many different transactionsare presented herein, many more and varied types of transactions may beprocessed by the monetary transaction system. In the following figures,“$C” refers to cash balance, “$DC” refers to a debit card (prepaid)balance and “SPIN” refers to a recharge PIN value.

FIG. 14 describes a subscriber deposit at an agent branch. Thesubscriber has a registered and activated (prepaid) debit card at anagent branch location. The prepaid debit card is associated with themobile wallet application in the subscriber's mobile device. As such,the debit card is linked to the subscriber's account in the monetarytransaction system 210. To deposit cash onto the mobile wallet, thesubscriber informs the agent that they want to deposit a specifiedamount of cash (1401). The agent takes the cash and notifies themonetary transaction system 210 of the deposit using their point of sale(POS) system or the agent mobile wallet application (1402), and themonetary transaction system 210 credits the subscriber's mobile walletaccount (1403). The funds collected at the cash register typically donot reach a bank account until the reconciliation and settlement offunds occurs between the agent and the mFS owner's bank.

The subscriber's bank then receives a settlement report from the cardprocessor and receives funds from the agent's bank. The agent or agentmanager physically deposits the cash into the subscriber's mobile walletaccount via their POS system or agent manager/agent mobile walletapplication. The monetary transaction system processes the depositrequest, increments the subscriber's mobile wallet balance within thecard processor and logs the transaction. An external card processorincrements the subscriber's mobile wallet balance and sends reports tothe bank for settlement on a regular (e.g. nightly) basis.

In one embodiment, the monetary transaction system 210 is implemented todeposit funds into a bank or credit union account using a mobile wallet.The communications module 215 of the monetary transaction system 210receives communication from an agent branch over a communication channel(step 1410). The agent communication indicates that a subscriber 205desires to deposit a specified amount of funds into a bank or creditunion account. The transaction processor 216 validates the status of thebank or credit union account (step 1420), determines if the agent branchis authorized to deposit money (step 1430), and performs a limit checkand/or a velocity check on the bank or credit union account (step 1440).The monetary transaction system then credits the bank or credit unionaccount with the specified amount of funds (step 1450), returns anotification to the agent branch confirming the deposit (step 1460) andnotifies the subscriber that the specified amount of funds was depositedin the bank or credit union account using at least one of thecommunication channels connected to the monetary transaction system(step 1470). Accordingly, cash may be deposited into a bank or creditunion account associated with a subscriber's mobile wallet.

FIG. 15 illustrates a subscriber deposit that is performed with anon-agent. In some economies, subscribers may have the ability toleverage other channels outside of agents to deposit funds onto theircard. One deposit method is a PIN-based recharge that allows asubscriber to purchase a PIN worth the deposit value. The PIN can thenbe redeemed via an interactive voice response (IVR) system or via thesubscriber's mobile wallet application. The mobile wallet applicationwill allow the monetary transaction system 210 to deposit the funds ontothe subscriber's card. The retailer's bank settles with the PIN cardprovider's bank and the PIN card provider's bank settles with the mFSplatform's bank for the deposit. The subscriber gives cash to the agent(1501) which increases the agent company's physical cash (1502). Thesubscriber uses IVR or their SIM Application to recharge mobile walletaccount using a PIN card (1503). In some cases, an agent may provide thePIN card (i.e. the prepaid debit card) to the subscriber. The monetarytransaction system 210 processes the subscriber deposit request,increments the subscriber's mobile wallet balance within the cardprocessor and logs the transaction. An external card processor decreasesthe subscriber's PIN card balance (1504), increments the subscriber'smobile wallet balance (1505) and send reports to the mFS platform bankfor settlement.

FIG. 16 illustrates a subscriber withdrawal at an agent branch. Towithdraw cash at an agent branch from a (prepaid) debit card, asubscriber submits a withdrawal request using the mobile walletapplication on their mobile device. The subscriber may also need toenter details about the agent branch that allows the monetarytransaction system 210 to determine if the subscriber has sufficientfunds on their debit card. The mFS platform then notifies the agentbranch that it can give cash to the subscriber. If the subscriber hassufficient funds, the monetary transaction system 210 will decrement thesubscriber's funds from their card (1601) and transfer it to the mobilewallet owner's account within the same card processor or bank. The agentbranch (1602) then provides the withdrawn cash to the subscriber (1603).

Accordingly, the subscriber requests a cash withdrawal from their ownmobile wallet account via the mobile wallet application. The agent oragent manager verifies the withdrawal request via POS authorization orSMS received on agent's phone and, once verified, gives cash to thesubscriber. The monetary transaction system 210 processes thesubscriber's withdrawal request, decrements the subscriber's mobilewallet balance within the card processor and logs the transaction. Anexternal card processor decrements the subscriber's mobile walletbalance and sends reports to the bank for settlement on a periodicbasis.

In one embodiment, the monetary transaction system 210 is implemented towithdraw funds from a bank or credit union account using a mobilewallet. The communication module 215 of the monetary transaction system210 receives a communication from a subscriber 205 over a communicationchannel 111 (step 1610). The subscriber communication indicates thatsubscriber 205 desires to withdraw a specified amount of funds from abank or credit union account. The transaction processor validates thestatus of the bank or credit union account (step 1620), determines ifthe balance of the bank or credit union account is sufficient toaccommodate the requested withdrawal for the specified amount of funds(step 1630) and performs a limit check and/or a velocity check on thebank or credit union account (step 1640).

The monetary transaction system 210 then returns a secure, perishablewithdrawal code to the subscriber 205 over at least one of thecommunication channels (step 1650) and receives a subsequent agentbranch communication indicating that the withdrawal code has beenpresented to an agent (step 1660). The monetary transaction system 210then debits the bank or credit union account by the specified amount offunds (step 1670), returns a notification to the agent branch confirmingthe withdrawal (1680) and notifies the subscriber that the specifiedamount of funds were withdrawn from the bank or credit union accountusing at least one of the communication channels connected to themonetary transaction system (step 1690). Accordingly, a subscriber canwithdraw cash stored on their mobile wallet from an agent branch or anon-agent branch.

FIG. 17A illustrates a subscriber withdrawal using an automated tellermachine (ATM). Subscribers in many countries have access to ATM machinesand can use their mobile wallets to perform withdrawals using their(prepaid) debit card at most ATMs. Banks provide ATMs to their customers(typically at no charge) and to non-customers (typically for a smallcharge). The subscriber requests a cash withdrawal from the subscriber'smobile wallet via the subscriber's debit card that is associated withthe mobile wallet. The bank providing the debit card may receivesettlement reports from the card processor and may transfer and/orsettle funds from subscriber's account to the ATM network bank. Anextern card processor decrements the subscriber's mobile wallet balance(1701) and sends transaction reports to the bank for settlement.Accordingly, once the withdrawal request has been received and theexternal card processor (e.g. Visa® or MasterCard®) (1702) has debitedthe debit card account, the ATM (1703) dispenses the withdrawn cash tothe subscriber (1704).

FIG. 17B illustrates a subscriber-to-subscriber money transfer. An mFSsubscriber (1705) may send money to another mFS subscriber (1706). To doso, subscriber A enters information identifying subscriber B (e.g. aphone number, email address or other identifier). The monetarytransaction system 210 determines if there are enough funds to completethe transaction, and if so, the monetary transaction system 210decrements subscriber A's debit card and credits subscriber B's debitcard. The subscriber, accordingly, may request to send money from theirown mobile wallet (i.e. money stored on a (prepaid) debit card) accountvia the subscriber mobile wallet application. The other subscriberreceives a notification that the balance of the debit card associatedwith their mobile wallet has increased. The bank receives a settlementreport from the debit card processor and transfers or settles funds fromsubscriber A's account to subscriber B's account (if necessary). Themonetary transaction system 210 processes the transfer request, updatessubscriber A's and subscriber B's debit cards that are associated withtheir mobile wallets and logs the transaction. The external cardprocessor decrements subscriber A's debit card balance, incrementssubscriber B's debit card balance and sends transaction reports to themFS platform bank for settlement.

FIG. 17C illustrates subscriber-to-non-subscriber money transfers. Inthis embodiment, subscriber A (an mFS subscriber) wishes to send moneyto another subscriber (a non-mFS subscriber). The transaction isinitiated in the same fashion as described above in FIG. 17B. However,since subscriber B does not have an mFS account, the monetarytransaction system 210 cannot credit them with money. Instead, themonetary transaction system 210 sends a communication (e.g. a SMS) tosubscriber B (1708) with an authorization code and instructions for howto pick up the cash. The monetary transaction system 210 puts a hold onsubscriber A's debit card for the amount transferred (1707). SubscriberB has a specified time period in which to pick up the cash before thehold expires and the amount is credited back to the debit cardassociated with subscriber A's mobile wallet account. The agent branchverifies the authorization code via POS or their agent mobile walletapplication (1709) and gives the cash to the non-subscriber (1710). (Insome countries, an agent network needs to be capable of giving cash to asubscriber based on the money transfer reference number).

The mFS bank receives a settlement report from the card processor andtransfer and settle funds from subscriber A's debit card to the agent'sbank (if necessary). The monetary transaction system 210 processes themoney transfer request, decrements subscriber A's mobile wallet balancewithin the card processor, generates a money transfer reference number,authorizes the reference number to be paid out by the agent and logs thetransaction. An external card processor decrements subscriber A's mobilewallet balance and sends periodic transaction reports to the bank forsettlement. Thus, as seen in FIGS. 17B and 17C, money may be transferredfrom subscriber to subscriber and from subscriber to non-subscriber.

Subscribers may similarly send money internationally to both subscribersand non-subscribers. FIG. 18A illustrates a subscriber-to-subscriberinternational money transfer. In this embodiment, subscriber A wishes tosend cash to subscriber B who resides in another country. As in theembodiments described above where money was transferred internationally,the monetary transaction system 210 may use one or more internationalmoney transfer organizations or remittance companies such as MoneyGram®to transfer the money. Subscriber A initiates the international moneytransfer using his or her phone. Subscriber A's debit card account isdecremented by the transfer amount (1801). The money is transferredbetween countries using an international money transfer organization(1802). In this case, subscriber B has an mFS eMoney account with aforeign mFS platform that is also affiliated with the selectedinternational money transfer organization. That organization can thencredit subscriber B's eMoney account directly (1803).

Thus, subscriber A requests to send money from their debit card accountvia the subscriber mobile wallet application. Subscriber B receives anotification (including a MoneyGram® Reference Number (MGRN) (or otherreference number when other international money transfer organizationsare used) and instructions on how to access the eMoney) that theireMoney balance has increased. The mFS bank receives settlement reportsfrom the debit card processor and transfers and/or settles funds fromsubscriber's account to the international organization's bank. Themonetary transfer system 210 processes the transfer request, updatesubscriber A's and subscriber B's eMoney balances and logs thetransaction. An external card processor decrements subscriber A's mobilewallet balance and sends periodic transaction reports to the bank forsettlement.

FIG. 18B illustrates a subscriber-to-non-subscriber international moneytransfer. In this embodiment, subscriber A wishes to send cash tosubscriber B who resides in another country. As above, the monetarytransaction system 210 uses an international money transfer organization(1806) to transfer the money between countries. Once the transfer hasbeen initiated by subscriber A, the international money transferorganization debits subscriber A's debit card account (1805) andtransfers that money to subscriber B. Subscriber B (1807) receives anotification (e.g. via SMS) with pick up instructions and a transfer IDnumber. Subscriber B can then go to an agent company (1808), show themthe notification (including, perhaps an authorization code), and receivethe transferred money (1809).

Similar to the transaction described in FIG. 18A, the embodiment of 19Aillustrates a transaction where a subscriber receives an internationalmoney transfer. Subscriber B (1901) initiates a money transfer usingtheir mobile wallet application. The international money transferorganization (1902) debits subscriber B's eMoney account balance. Thismoney is then transferred by the international money transferorganization to subscriber A. Subscriber A receives a notification alongwith a transfer ID number indicating that their debit card account hasbeen credited with the transferred money (1903).

FIG. 19B illustrates a non-subscriber-to-subscriber international moneytransfer. This scenario is very similar to that described in FIG. 19Afrom the mFS subscriber's perspective, except that their eMoney accountis credited here, and their debit card account was credited in 19A. Theinitiator, subscriber B (1905), does not have an mFS account and, as aresult, takes their cash to an international money transfer organization(e.g. MoneyGram®) or other remittance company's agent (1906) to send itto subscriber A's mobile wallet eMoney account. The international moneytransfer organization (1907) then transfers the specified amount tosubscriber A (1908) and subscriber A's mobile wallet eMoney account iscredited with the amount of the transfer. Subscriber A may receive atransaction ID number, along with an indication that the transfer hasoccurred. The mFS bank may receive settlement reports from the cardprocessor and settle funds from the international money transferorganization's bank to subscriber A's mobile wallet account. Themonetary transaction system processes the money transfer request,updates subscriber A's mobile wallet balance within the card processorand logs the transaction. An external card processor incrementssubscriber A's mobile wallet balance and sends periodic transactionreports to the mFS bank for settlement.

Other functionality described above in relation to using an eMoneymobile wallet account may also apply to banked subscribers using a debitcard associated with their mobile wallet. Such subscribers may buyairtime for their mobile device, pay bills, make retail purchases,receive direct deposits, and perform other functionality.

In one embodiment, the monetary transaction system 210 is implemented toadd a mobile wallet platform stored value account to a mobile wallet.The stored value account may include eMoney or other monetary credits.In the embodiment, communication module 215 of monetary transactionsystem 210 may receive subscriber data for an unbanked subscriber 205over a communication channel. The transaction processor may performvalidation checks on the unbanked subscriber to validate that theunbanked subscriber is not exceeding a specified allowable number ofaccounts per subscriber. The monetary transaction system 210 may thensend subscriber data to another entity (such as a third partyverification system) for identification of the unbanked subscriber. Themonetary transaction system 210 receives results from the third partyverification system indicating that the subscriber data appropriatelyidentifies the unbanked subscriber, creates a stored value account forthe unbanked subscriber that maintains a recorded balance for thecreated stored value account, adds the stored value account to theunbanked subscriber's mobile wallet and notifies the unbanked subscriberof the addition of the stored value account over at least onecommunication channel connected to the mobile wallet platform.

In another embodiment, the monetary transaction system 210 isimplemented to add a third party stored value account to a mobilewallet. The monetary transaction system 210 receives unbanked subscriberdata, including account details, over a communication channel. Thetransaction processor 216 performs a validation check on the unbankedsubscriber to validate that the unbanked subscriber is not exceeding aspecified allowable number of accounts per subscriber. If the validationcheck is ok, the monetary transaction system 210 sends subscriber datato a third party verification system for identification of the unbankedsubscriber. In some cases, validating the status of the sender or therecipient includes performing a check on the specified sender orrecipient to comply with the office of foreign assets control. Themonetary transaction system 210 then receives results from the thirdparty verification system indicating that the subscriber dataappropriately identifies the unbanked subscriber, and submits theunbanked subscriber's account details to a third party accountprocessor. The monetary transaction system 210 receives an indicationfrom the third party account processor that third party accountprocessor created a third party stored value account for the subscriber.The transaction processor maintains a link between the subscriber dataand the third party stored value account and adds the third party storedvalue account to the unbanked subscriber's mobile wallet. The monetarytransaction system 210 then notifies the unbanked subscriber of theaddition of the third party stored value account over a communicationchannels connected to the monetary transaction system.

In another embodiment, the monetary transaction system 210 isimplemented to add a bank or credit union account to a mobile wallet.The communication module 215 receives subscriber data, including bank orcredit union account details, over a communication channel 111. Thetransaction processor 216 performs validation checks on the subscriberto validate that the subscriber is not exceeding a specified allowablenumber of accounts per subscriber and sends subscriber data to a thirdparty verification system for identification of the subscriber. Thecommunication module then receives results from the third partyverification system indicating that the subscriber data appropriatelyidentifies the subscriber. Upon receiving these results, the monetarytransaction system 210 submits bank or credit union account details forvalidation by the transaction processor, receives an indication that thebank or credit union account details correspond to a valid bank orcredit union account, maintains a link between the subscriber data andthe bank or credit union account and notifies the subscriber of the bankor credit union account validation over a communication channel.

In still another embodiment, the monetary transaction system isimplemented to add a debit or credit card account to a mobile wallet.The communication module 215 receives subscriber data, including a debitor credit card account number, over a communication channel 111connected to the monetary transaction system. The transaction processorperforms validation checks on the subscriber to validate that thesubscriber is not exceeding a specified allowable number of accounts persubscriber. The communication module sends subscriber data to a thirdparty verification system for identification of the subscriber andreceives results from the third party system indicating that thesubscriber data appropriately identifies the subscriber. The monetarytransaction system 210 securely stores the debit or credit card accountnumber for access by the mobile wallet (e.g. in memory 217 ortransaction database 225), adds the debit or credit card account numberto the subscriber's mobile wallet, and notifies the subscriber of theaddition of the debit or credit card account number. It should be notedthat many other transactions can take place over the monetarytransaction system, and that the embodiments described herein should notbe read as limiting.

Embodiments of the invention can adhere to Know Your Customer (KYC)rules in the US by performing Customer Identification Program (CIP)checks as required by the Bank Secrecy Act and US PATRIOT Act. A minimumamount of information can be gathered about a customer, such as, forexample, first name, last name, date of birth, government ID Type,government ID number and address. The CIP processes are designed tovalidate customer identity against government blacklists and assists inthe prevention of money laundering and terrorist financing. Acombination of non-documentary and documentary verification can be usedto ensure beyond a reasonable doubt the identity of the customer.

Non-documentary verification can occur through the presentment of theinformation that was collected from the user to an external third party,such as, for example, Lexis Nexis®. Documentary verification can occurif non-documentary verification fails, then the user is asked to presentan unexpired government ID. Various differ forms of identificationincluding driver's license, passport, alien identification (e.g., greencard or work visa), and Mexican Consular identification card, can beaccepted.

Embodiments of the invention can perform Anti-Money Laundering (AML) andCombating the Financing of Terrorism (CFT) checks. AML and CFT checkscan be performed using transaction monitoring methods to flag names andsuspicious transactions for further investigation. The mobile walletplatform can perform AML and CFT checks on all electronic financialtransactions to ensure that electronic funds are not being used formoney laundering or terrorism. Transaction limits can be placed on useraccounts. The transaction limits are fully configurable for eachparticular use case, channel and payment method that allows maximumflexibility to restrict higher risk use cases. Velocity checks can alsobe performed. Velocity Checks ensure that subscribers are not abusingthe mobile wallet platform within the allowable limits.

FIGS. 20A through 20F depicts relationships between embodiments ofvarious components within the monetary transaction system depicted inFIG. 1. In particular, FIGS. 20A through 20F depict communicationsbetween the specific components within the monetary transaction systemduring an operation to deposit of funds within a financial account. Thedepicted interactions are representative of computer executed functionsthat enable the deposit of money through a mobile transaction systemthat is capable of functioning without an associated bank account.

FIGS. 21A through 21I depicts relationships between embodiments ofvarious components within the monetary transaction system depicted inFIG. 1. In particular, FIGS. 21A through 21I depict communicationsbetween the specific components within the monetary transaction systemduring an operation to withdraw funds from a financial account. Thedepicted interactions are representative of computer executed functionsthat enable the withdrawal of money through a mobile transaction systemthat is capable of functioning without an associated bank account.

FIGS. 22A through 22J depicts relationships between embodiments ofvarious components within the monetary transaction system depicted inFIG. 1. In particular, FIGS. 22A through 22J depict communicationsbetween the specific components within the monetary transaction systemduring an operation to transfer funds between financial accounts. Thedepicted interactions are representative of computer executed functionsthat enable the transfer of money through a mobile transaction systemthat is capable of functioning without an associated bank account.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed is:
 1. A monetary transaction system for conductingmonetary transactions between subscribers and other entities, themonetary transaction system comprising: one or more processors; astorage system configured to store financial transaction details,customer profiles and money containers; an integration tier configuredto manage mobile wallet sessions, the integration tier also including acommunication application programming interface (API) and othercommunication mechanisms to accept messages from channels; notificationservices configured to send notifications through different notificationchannels; a payment handler configured to use APIs of different paymentprocessors including one or more APIs of banks, credit and debit cardsprocessors, and bill payment processors; a security service configuredto perform subscriber authentication; an entity profile saved with themonetary transaction system, the entity profile associated with anentity that is to be involved in a specified transaction; and one ormore computer-readable media having stored thereon executableinstructions that when executed by the one or more processors configurethe monetary transaction system to perform at least the following:receiving a communication message from a mobile device over one of aplurality of channels connected to the monetary transaction system, thecommunication message being received by the integration tier of themonetary transaction system, the communication message indicating that asubscriber desires to perform a digital financial transaction,validating a status of the subscriber's account, wherein validating thestatus of the subscriber's account comprises communicating from theintegration tier to the storage system to query attributes of thesubscriber's account, and receiving confirmation that the digitalfinancial transaction has been performed.
 2. A method for conductingmonetary transactions between subscribers and other entities within amonetary transaction system, the method executed on a computer systemcomprising one or more processors, the method comprising: initiating astorage system configured to store financial transaction details,customer profiles and money containers; initiating an integration tierconfigured to manage mobile wallet sessions, the integration tier alsoincluding a communication application programming interface (API) andother communication mechanisms to accept messages from channels;initiating notification services configured to send notificationsthrough different notification channels; initiating a payment handlerconfigured to use APIs of different payment processors including one ormore APIs of banks, credit and debit cards processors, and bill paymentprocessors; initiating a security service configured to performsubscriber authentication; initiating an entity profile saved with themonetary transaction system, the entity profile associated with anentity that is to be involved in a specified transaction; receiving acommunication message from a mobile device over one of a plurality ofchannels connected to the monetary transaction system, the communicationmessage being received by the integration tier of the monetarytransaction system, the communication message indicating that asubscriber desires to perform a digital financial transaction;validating a status of the subscriber's account, wherein validating thestatus of the subscriber's account comprises communicating from theintegration tier to the storage system to query attributes of thesubscriber's account; and receiving confirmation that the digitalfinancial transaction has been performed.
 3. A monetary transactionsystem for conducting monetary transactions between subscribers andother entities, the system comprising: one or more processors; and (i) astorage system for storing financial transaction details, customerprofiles and money containers, the storage system configured to:validate a status of a subscriber's account, wherein validating thestatus of the subscriber's account comprises communicating from anintegration tier to the storage system to query attributes of thesubscriber's account; (ii) the integration tier comprising acommunication application programming interface (API) and othercommunication mechanisms to accept messages from channels, theintegration tier configured to: manage mobile wallet sessions, andreceive a communication message from a mobile device over one of aplurality of channels connected to the monetary transaction system, thecommunication message being received by the integration tier of amonetary transaction system, the communication message indicating thatthe subscriber desires to perform a digital financial transaction; (iii)a payment handler configured to: use APIs of different paymentprocessors including one or more APIs of banks, credit and debit cardsprocessors, bill payment processors; (iv) a security service configuredto perform subscriber authentication; and (v) an entity profile savedwith the monetary transaction system, the entity profile associated withan entity that is to be involved in a specified transaction.
 4. Acomputer-readable media comprising one or more physicalcomputer-readable storage media having stored thereoncomputer-executable instructions that, when executed at a processor,cause a computer system to perform a method for conducting monetarytransactions between subscribers and other entities within a monetarytransaction system, the method comprising: initiating a storage systemconfigured to store financial transaction details, customer profiles andmoney containers; initiating an integration tier configured to managemobile wallet sessions, the integration tier also including acommunication application programming interface (API) and othercommunication mechanisms to accept messages from channels; initiatingnotification services configured to send notifications through differentnotification channels; initiating a payment handler configured to useAPIs of different payment processors including one or more APIs ofbanks, credit and debit cards processors, and bill payment processors;initiating a security service configured to perform subscriberauthentication; initiating an entity profile saved with the monetarytransaction system, the entity profile associated with an entity that isto be involved in a specified transaction; receiving a communicationmessage from a mobile device over one of a plurality of channelsconnected to the monetary transaction system, the communication messagebeing received by the integration tier of the monetary transactionsystem, the communication message indicating that a subscriber desiresto perform a digital financial transaction; validating a status of thesubscriber's account, wherein validating the status of the subscriber'saccount comprises communicating from the integration tier to the storagesystem to query attributes of the subscriber's account; and receivingconfirmation that the digital financial transaction has been performed.